xend: Fix race in vfb/vkbd device setup.
authorkfraser@localhost.localdomain <kfraser@localhost.localdomain>
Wed, 25 Apr 2007 08:44:20 +0000 (09:44 +0100)
committerkfraser@localhost.localdomain <kfraser@localhost.localdomain>
Wed, 25 Apr 2007 08:44:20 +0000 (09:44 +0100)
commitefe6d12251770146719a478f95054a79c634f3e5
tree66c9e525ce36ba6ce953ad9cd65fcc5235395cbe
parent260c2c91b7deab998a801ca77580fb6f2d3c1704
xend: Fix race in vfb/vkbd device setup.

 1. XendDomainInfo._createDevices() gets a list of devices to be
    created from XendConfig.ordered_device_refs().
    On a simple guest, this has 4 devices, vfb, vbd, vif, vkbd - in
    that order.

 2. It iterates over those devices, creating the appropriate
    DevController subclass instance, and then calling createDevice()
    on that object.

 3. When createDevice() is called on the vfb  device, it spawns
    xen-vncfb daemon.

 4. During startup xen-vncfb writes into the backend paths
            /local/domain/0/backend/vfb/0
     And
            /local/domain/0/backend/vkbd/0

 5. When createDevice() is called on the vkbd device in XenD, if the
    2nd xenstore path write from step 4 has occurred, then you'll hit
    the 'Device 0 (vkbd) is already connected' error. If the 2nd path
    write didn't complete yet then everything is fine.

I think the reason it often works once after boot is that loading
xen-vncfb from disk the first time around is just enough of a slow
down to ensure step 5 occurs before the 2nd xenstore write in step 4
has occurred.

The key seems to be to ensure the vkbd device is initialized in
xenstore before the vfb device - this ensures all the xenstored setup
from XenD is complete before the xen-vncfb daemon starts. I'm now able
to create & destroy a domain many times over with this patch & never
hit the error message any more.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
tools/python/xen/xend/XendConfig.py